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Beschreibung: 

Verfahren zum direkten Aufrufen einer Funktion mittels eines Softwa- 
remoduls durch einen Prozessor mit einer Memory-Management-Unit 
5 (MMU) 

Die Erfindung betrifft ein Verfahren zum direkten Aufrufen einer Zielfunk- 
tion mittels einer Startfunktion durch einen Prozessor mit einer Memory- 
Management-Unit (MMU) in einem durch ein Betriebssystem betriebenen 
10 Computer. 

Bei Multitasking-Betriebssystemen werden mehrere Programme (quasi-) 
gleichzeitig ausgefuhrt. Da Programme nicht immer fehlerfrei ablaufen, 
mussen Multitasking-Betriebssysteme im Fall eines Programmfehlers den 
15 Schaden moglichst gering halten. Dazu isolieren Multitasking- 
Betriebssysteme den Speicher (engl.: Memory) der einzelnen Programme 
derart voneinander, daC das Fehlverhalten eines Programmes keines der 
anderen Programme in Mitleidenschaft ziehen kann. Zur Vereinfachung wird 
im folgenden von Betriebssystemen gesprochen, wobei stets Multitasking- 
.20 Betriebssysteme gemeint sind. 

Die Memory-Isolierung besteht in der Trennung zwischen virtuellem und 
physikalischem Memory. Memoryzugriffe von Programmen finden stets auf 
virtuellem und nicht auf physikalischem Memory statt. Virtuelles Memory 

25 wird vom Prozessor durch Auslesen von Tabellen auf physikalisches Memo- 
ry abgebildet. Dazu verfiigt der Prozessor iiber eine Memory-Management- 
Unit (kurz: MMU). Es ist Aufgabe der Betriebssysteme, diese Tabellen 
anzulegen und zu verwalten. Diese Tabellen werden als Memory-Kontexte 
bezeichnet. Die Memory-Kontexte liegen selbst im Memory des Rechners 

30 und werden von der MMU gelesen. Im Gegensatz zu Programmen finden 
Memoryzugriffe der MMU stets auf physikalischem und nicht auf virtuellem 
Memory statt. Die MMU benotigt zum Zugriff auf einen Memory-Kontext 
dessen physikalische Adresse. Dazu verfiigt der Prozessor uber ein MMU- 
Steuerregister. Im MMU-Steuerregister ist die physikalische Adresse des 

35 aktuell giiltigen Memory-Kontextes abgelegt. 
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Jedem Programm ist ein eigener Memory-Kontext zugeordnet. Ein Pro- 
gramm mit seinem eigenen Memory-Kontext wird als Task bezeichnei. Die 
Memory-Kontexte werden von Betriebssystemen derart gestaltet, daB sie sich 
bezuglich des physikalischen Memorys nicht iiberlappen. Dadurch ist die 
5 Memory-Isolierung zwischen den Tasks gewahrleistet. Die Fehlfunktion 
eines Programms findet somit nur in . einem Memory-Kontext 
(Speicherkontext) statt und kann andere Programme in anderen Memory- 
Kontexten nicht beeinflussen. 

10 Das Prinzip der physikalischen Isolierung der Memory-Kontexte zweier 
Tasks ist in der Figur 1 der beigefugten Zeichnungen dargestellt. 

Durch die Memory-Isolierung wird ein Datenaustausch zwischen Tasks 
unmoglich gemacht. Der Datenaustausch ist jedoch notwendig, um die 

15 Ausgangsdaten einer Task einer anderen Task zur Verfugung zu stellen (z.B. 
fiir den Datenaustausch zwischen einem Datenbankprogramm und einem 
Textverarbeitungsprogramm). Betriebssysteme bieten daher Mittel zur 
Intertaskkommunikation. Durch die Intertaskkommunikation darf jedoch 
nicht jene Liicke wieder geoffnet werden, die durch Memory-Isolierung 

20 geschlossen wurde. Deswegen erfolgt die Intertaskkommunikation von 
Betriebssystemen generell durch ein Umkopieren von Daten. Die Betriebssy- 
steme "transportieren" gewissermaBen eine Kopie der Daten von einer Task 
zur anderen. Durch diesen Mechanismus konnen Tasks Daten austauschen, 
ohne gegenseitigen Zugriff auf ihre Daten zu haben. 

25 

Der Datenaustausch iiber ein Betriebssystem hat den Nachteil, dafi der 
hochst mogliche Datendurchsatz wegen des Umkopierens der Daten nicht 
erreicht werden kann, Es gibt jedoch Anwendungen, in denen es notwendig 
ist, den hochst moglichen Datendurchsatz zu erreichen. Fur solche Anwen- 
30 dungen bieten Betriebssysteme die Verwendung von Shared-Memory 
(gemeinsamer Speicher) zum direkten gegenseitigen Datenzugriff verschie- 
dener Tasks an. Bei Shared-Memory sind die Memory-Kontexte der betei- 
ligten Tasks derart gestaltet, daB sie sich einen bestimmten physikalischen 
Memorybereich teilen. 

35 V 
In Fig. 2 der beigefugten Zeichnungen ist das Prinzip des gemeinsamen 
Speicherzugriffs zweier Tasks dargestellt. 



Shared-Memory widerspricht dem Prinzip der Memory-Isolierung. Dieser 
Widerspruch ist jedoch nicht problematisch, da Tasks nicht beliebig zur 
Verwendung von Shared-Memory veranlaBt werden konnen. Wenn Tasks 
5 untereinander den hochst moglichen Datendurchsatz erreichen sollen, dann 
mussen sie Programmfunktionen umfassen, die explizit Shared-Memory 
anfordern. Eine Task mufi daher bewulit durch den Programmierer so 
konfiguriert werden, daC sie mit bestimmten anderen Tasks Shared-Memory 
verwendet. Der Programmierer wird daher besondere Rucksicht auf die 
10 Gefahren durch Fehlfunktionen der anderen Tasks nehmen, um weitere 
Auswirkungen derartiger Fehlfunktionen moglichst zu vermeiden. 

Neben dem Datenaustausch ist auch der Ereignisaustausch, d.h. der Aus- 
tausch des Zustandswechsels von Daten, in der Kegel nur iiber die Inter- 
15 taskkommunikation der Betriebssysteme vorgesehen. Um nicht wieder die 
Lucke zu offnen, die durch die Memory-Isolierung geschlossen wurde, 
werden Ereignisse von Betriebssystemen registriert und zu gegebener Zeit 
weitergeleitet. Die Betriebssysteme *'transportieren" Ereignisse mit ahnli- 
chen Mechanismen wie Daten von einer Task zur anderen. 

20 

Der Ereignisaustausch iiber ein Betriebssystem hat den Nachteil, dali der 
Weiterleitungszeitpunkt von dem Betriebssystem und den anderen durch das 
Betriebssystem ausgefuhrten Tasks abhangt. Es ist also nicht moglich, einen 
Ereignisaustausch mit optimaler Determiniertheit, d.h. mit exakter Be- 

25 stimmtheit des Zeitpunktes der Weiterleitung, durchzufuhren. Es gibt jedoch 
eine Anzahl von Anwendungen, bei denen es notwendig ist, die hochst 
mogliche Determiniertheit zu erreichen. In Analogic zu Shared-Memory lage 
. es nun nahe, daC die Betriebssysteme einen entsprechenden Bypass- 
Mechanismus anbieten. Keines der existierenden Betriebssysteme bietet 

30 jedoch einen solchen Mechanismus. 

Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren zum 
direkten und unmiltelbaren Ereignisaustausch zwischen verschiedenen Tasks 
zu schaffen. 

35 

Diese Aufgabe wird dadurch gelost, daB die Startfunktion Bestandteil einer 
ersten Task mit einem ersten Speicherkontext ist und die Zielfunktion in 
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einem anderen Speicherkontext liegt und dafi die erste Task einen Kon- 
textwechsel von dem ersten in den anderen Speicherkontext durchfuhrt, der 
nach der Ausfuhrung der Zielfunktion riickgangig gemacht wird. 

5 Mit anderen Worten umfaBt die erste Task eine Funktion, die unabhangig 
vom Betriebssystem einen Aufruf der Zielfunktion steuert und durchfuhrt. 
Die Zielfunktion wird somit unter Umgehung des Taskwechslers (engl.: 
Scheduler) des Betriebssystems unmittelbar und mit hdchster Determiniert- 
heit aufgerufen. Die erste Task ubernimmt dabei eine der typischen Aufga- 
10 ben des Betriebssystems. 

Die bevorzugten Verfahrensschritte zur optimalen und betriebssicheren 
Durchfiihrung dieses Verfahrens ergeben sich aus den Unteranspruchen und 
der nachfolgenden Beschreibung von Ausfuhrungsformen der Erfindung. Die 
15 Erfindung bezieht sich ferner auf ein Softwareprogramm zur Durchfiihrung 
eines erfindungsgemaBen Verfahrens sowie auf einen maschinenlesbaren 
Datentrager, auf dem ein derartiges Softwareprogramm abgespeichert ist. 

Softwaretechnisch geschieht die direkteste (und determinierteste) Form der 
20 Ereignisweiterleitung durch einen Funktionsaufruf. Daher wird in einer Task 
eine Funktion einer anderen Task aufgerufen, was dem Aufrufen einer 
Funktion in einem anderen Memory-Kontext entspricht. Ein solcher Aufruf 
findet im Gegensatz zur Intertaskkommunikation „direkt" statt und wird 
daher als Direktaufruf bezeichnet. 

25 

Der Direktaufruf ist ein Dienst, der von einer Task angeboten wird. Die 
Task, die den Dienst anbietet, eine Funktion einer anderen Task direkt 
aufzurufen, wird daher als Server bezeichnet. Der Programmteil des Ser- 
vers, der den Direktaufruf durchfuhrt, wird als Startfunktion bezeichnet. Die 
30 zweite Task, von der eine Funktion direkt aufgerufen werden soli, wird als 
Client bezeichnet, da sie den Dienst des Servers in Anspruch nimmt. Die 
direkt aufzurufende Funktion innerhalb des Clients wird als Zielfunktion 
bezeichnet. 

35 Ahnlich der Verwendung von Shared-Memory muB der erfindungsgemaBe 
Funktionsaufruf durch den Programmierer in dem Client vorgesehen werden. 
Der direkte Aufruf einer Funktion einer Task kann also nicht durch andere 
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Programme erzwungen werden. Client und Server miissen bewuBt aufeinan- 
der abgestimmt werden. um die hochst mogliche Determiniertheit mittels 
Direktaufruf zu erreichen. 

5 Um die AUgemeingultigkeit des Verfahrens zu gewahrleisten, muB die 
Zielfunktion auch vom Client selbst aufrufbar bleiben. Weiterhin soUten 
keine compilerspezifischen Einstellungen oder Funktionen eingesetzt 
werden, da solche Spezialitaten nicht auf alien gangigen Rechnerplattformen 
einheitlich verfiigbar sind. 

10 

Um einen Direktaufruf vorzubereiten, muB der Client die Memory-Adresse 
(kurz: Adresse) seiner Zielfunktion an den Server ubermitteln. Dazu nutzt 
der Client die Intertaskkommunikation der Betriebssysteme. Der Server hat 
zur Laufzeit die Aufgabe, den Direktaufruf durchzufiihren. Das Zusammen- 
15 wirken von Client und Server ist in Fig. 3 der Zeichnungen dargestellt. 

Die im Speicherkontext (kurz: Kontext) des Clients giiltige Adresse der 
Zielfunktion ist jedoch im Kontext des Servers nicht giiltig, da es sich um 
eine virtuelle Adresse handelt. Damit der Server diese Adresse sinnvoll 
20 verwenden kann, muB er die physikalische Adresse der Zielfunktion kennen. 
Die physikalische Adresse der Zielfunktion ist im Kontext des Clients 
abgelegt. Zur Ermittlung der physikalischen Adresse der Zielfunktion muB 
also ein lesender Zugriff auf den Kontext des Clients ermoglicht werden. 

25 Da der Server wegen spater aufgefuhrter Grunde unbedingt den lesenden 
Zugriff auf den Kontext des Clients benotigt, wird die Adresse des Client- 
Kontextes an den Server ubermittelt. Da der Server auf die virtuelle Adresse 
des Client-Kontextes nicht zugreifen kann, muB der Client die physikalische 
Adresse seines Kontextes an den Server ubermitteln. 

30 

Im MMU-Steuerregister des Prozessors ist die physikalische Adresse des 
Kontextes abgelegt. Der Client. ermittelt die physikalische Adresse seines 
Kontextes durch Auslesen des MMU-Steuerregisters. 

35 Der Server kann jedoch nicht lesend auf physikalisches Memory zugreifen, 
sondern nur auf viriuelles Memory seines eigenen Kontextes. Die Betriebs- 
systeme bieten jedoch Mechanismen an, um physikalisches Memory in einen 
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Kontext einzublenden. Dieser Vorgang wird als Mapping (deutsche Bedeu- 
tung „Abbilden") bezeichnet. Dutch Mapping der physikalischen Adresse 
des Client-Kontextes in den Server-Kontext hatte der Server die Moglich- 
keit, den Client-Kontext zu lesen. Damit kann er die physikalische Adresse 
5 aus der im Client-Kontext gultigen virtuellen Adresse der Zielfunktion 
ermitteln. 

Durch Mapping der physikalischen Adresse der Zielfunktion in den Server- 
Kontext hatte die Startfunktion die Moglichkeit, den Direktaufruf durchzu- 
10 fiihren. 

Im allgemeinen greifen Funktionen jedoch auf absolut adressierte Daten zu. 
AuBerdem konnen Funktionen auch weitere Funktionen aufrufen. Ferner 
konnen innerhalb der Funktionen selbst absolut adressierte Sprunge durchge- 

15 fiihrt werden. Die Kenntnis der physikalischen Adresse der Zielfunktion 
geniigt daher nur dann, wenn die Zielfunktion nicht auf absolut adressierte 
Daten zugreift, keine weiteren Funktionen aufruft und keine absolut adres- 
sierten Sprunge enthalt. Dieser Fall kommt jedoch in der Praxis kaum vor, 
da eine Funktion mit solchen Einschrankungen fast keine sinnvollen Ergeb- 

20 nisse erzielen kann. 

Urn diese Einschrankungen aufzuheben, konnte von alien absoluten virtuel- 
len Adressen in der Zielfunktion die physikalische Adresse ermittelt und in 
den Server-Kontext gemappt werden. Dann miifiten in der Zielfunktion alle 

25 im Client-Kontext gultigen Adressen in die entsprechenden gemappten 
Adressen im Server-Kontext ersetzt werden. Dieses Verfahren ware jedoch 
sehr aufwendig, da der Programmcode dazu disassembliert werden muB. 
AuBerdem wurde ein Verandern der Adressen in der Zielfunktion bedeuten, 
daB die Zielfunktion (und alle Funktionen, die von ihr aufgerufen werden) 

30 im Client-Kontext selbst nicht mehr lauffahig ware. Von dieser Verfahrens- 
variante (Verfahrensvariante 1) wird daher Abstand genommen. 

Statt dessen wird gemaB dem Patentanspruch 1 ein Verfahren beschrieben, in 
dem die Startfunktion aus ihrem Kontext in den Kontext der Zielfunktion 
35 wechselt. 
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Der Server kennt die physikalische Adresse des Client-Kontextes. Anstelle 
des Mappings der Zielfunktion in seinen eigenen Kontext kann die Start- 
funktion das MMU-Steuerregister mit der physikalischen Adresse des Client- 
Kontextes beschreiben. Damit hat die Startfunktion einen Kontextwechsel 
5 zum Client durchgefuhrt. Sie kann den Direktaufruf durchfuhren, da alle 
Daten und weiteren Funktionen, die von der Zielfunktion aufgerufen 
warden, im Kontext des Clients liegen, in dem der Aufruf stattfindet. Nach 
der Durchfuhrung des Direktaufrufes beschreibt die Startfunktion das MMU- 
Steuerregister wieder mit dem ursprunglichen Wert und wechselt dadurch 
10 zuriick in den Server-Kontext. 

Damit diese Variante des Direktaufrufes (Verfahrensvariante 2) funktionie- 
ren kann, muB die Startfunktion im Shared-Memory von Client und Server 
liegen. Ansonsten wurde im Moment des Wechsels vom Server-Kontext in 

15 den Client-Kontext die Startfunktion ihre Giiltigkeit verlieren, und eine 
Ruckkehr des Zielfunktionsaufrufes in die Startfunktion ware nicht mehr 
moglich. Die Betriebssysteme bieten jedoch keine Moglichkeit, um Pro- 
grammcode in Shared-Memory zu legen. Nur Daten konnen im Shared- 
Memory liegen. Die fehlende Moglichkeit der Betriebssysteme, Pro- 

20 grammcode in Shared-Memory zu legen, kann i.A. nachgebildet werden 
durch schreibende Zugriffe auf den entsprechenden Kontext. Im konkreten 
Fall wurde der Teil des Server-Kontextes, der die Startfunktion enthalt, zum 
Client-Kontext hinzukopiert werden. Durch diesen Kopiervorgang liegt die 
Startfunktion im Kontext des Clients, so daB die Ruckkehr des Zielfunkti- 

25 onsaufrufes in die Startfunktion moglich wird. 

Es kommt jedoch ein Problem hinzu, denn ein Kontextwechsel gehort zu den 
ureigensten Aufgaben der Betriebssysteme. Die Betriebssysteme konnen 
daher einen eigenmachtigen Kontextwechsel durch eine Task nicht verarbei- 

30 ten. Daher speichern die Betriebssysteme beim Taskwechsel (engl.: Schedu- 
ling) die physikalischen Kontextadressen der Tasks ab, statl sie jedesmal aus 
dem MMU-Steuerregister auszulesen. Wenn nun eine Task selbstandig einen 
Kontextwechsel durchgefuhrt hat und dann vom Taskwechsler (engl.: 
Scheduler) eines Betriebssystems unterbrochen wird, wird das Betriebssy- 

35 stem der Task bei der nachsten Zuteilung von Rechenzeit ihren ursprungli- 
chen Kontext zuweisen, und nicht den Kontext, in den die Task gewechselt 
hatte. Damit wurde die Zielfunktion im falschen Kontext ausgefuhrt werden. 
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Der Server mufi daher zur Laufzeit der Startfunktion und der aufgerufenen 
Zielfunktion ein Scheduling durch die Betriebssysteme unbedingt vermeiden. 
Diese Bedingung an den Server wird als Serverbedingung bezeichnet. 

5 Weiterhin muB gewahrleistet sein, dafi von der Zielfunktion keine Betriebs- 
systemfunktion aufgerufen wird, da die Betriebssysteme einen Aufruf aus 
diesem Kontext nicht verarbeiten konnen (sie haben ja schlieBlich nicht in 
diesen Kontext gewechselt). Das Verhalten der Betriebssysteme ware bei 
solchen Aufrufen nicht vorhersehbar, Diese Bedingung an den Client wird 
10 als Erste Clientbedingung bezeichnet. 

Da der Direktaufruf asynchron zur Laufzeit des Clients stattfindet, und zwar 
derart, dali wahrend des Direktaufrufes der Client wegen der Serverbedin- 
gung unterbrochen ist, kann es zu Problemen kommen, wenn der Client 

15 selbst die Zielfunktion (oder Funktionen, die von der Zielfunktion aufgeru- 
fen werden) aufruft. Wenn wahrend des Aufrufes der Zielfunktion durch den 
Client ein Scheduling zum Server stattfindet, der dann seinerseits ebenfalls 
die Zielfunktion aufrufen wurde, dann ware die Zielfunktion zum zweiten 
Mai aufgerufen, bevor der erste Aufruf beendet ware. Ein solcher Zweitauf- 

20 ruf verlangt von einer Funktion die Eigenschaft, wiedereintrittsfahig zu sein. 
Wiedereintrittsfahige Funktionen sind sehr aufwendig zu konstruieren, 
Damit diese aufwendige Konstruktion nicht notwendig ist, darf der Client 
nur dann selbst die Zielfunktion (oder Funktionen, die von der Zielfunktion 
aufgerufen werden) aufrufen, wenn der Server die Zielfunktion mit Sicher- 

25 heit nicht aufrufen kann. Diese Bedingung an den Client wird als Zweite 
Clientbedingung bezeichnet. 

Weiterhin darf der Client zu Zeitpunkten, in denen der Server die Zielfunk- 
tion aufrufen kann, nur derart auf Daten zugreifen, die durch den Aufruf der 

30 Zielfunktion verwendet oder verandert werden konnten, daB der Zugriff 
innerhalb eines Prozessortaktes abgeschlossen oder iiber Flaggen verriegelt 
ist. Andernfalls konnte der Client, wahrend er auBerhalb seiner Zielfunktion 
auf Daten zugreift, mitten im Datenzugriff vom Server unterbrochen wer- 
den. Ein Zugriff auf Daten, der innerhalb eines Prozessortaktes abgeschlos- 

35 sen ist, wird als atomarer Zugriff bezeichnet. Diese Bedingung an den Client 
wird als Dritte Clientbedingung bezeichnet. 
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Der Server mu6 zur Erfullung der Serverbedingung den Scheduler der 
Beiriebssysteme deaktivieren. Der Scheduler der Betriebssysteme arbeitet 
interruptgesteuert. Die Startfunktion mufi daher iiber ein Prozessorsteuerre- 
gister die Interruptverarbeitung anhalten und stellt dadurch sicher, daB sie 
5 nicht vom Scheduler eines Betriebssystems unterbrochen werden kann. 

Der Client erfiillt die Erste Clientbedingung durch Unterlassung von 
expliziien Betriebssystemaufrufen in der Zielfunktion. Allerdings muB auch 
sichergestellt sein, daB in der Zielfunktion keine impliziten Betriebssyste- 
10 maufrufe stattfinden. Implizite Betriebssystemaufrufe finden statt, wenn 
Ausnahmesituationen eintreten wie z.B. eine Division durch Null. Daher 
muB die Zielfunktion fehlerfrei programmiert sein, urn keine Ausnahmesi- 
tuationen zu provozieren, die einen Betriebssystemaufruf zur Folge haben. 

15 Die Betriebssysteme lagern bei Mangel an physikalischem Arbeitsspeicher 
automatisch Telle des Speichers (Memory) auf Festplatte aus. Greift eine 
herkommliche Task auf ausgelagertes Memory zu, dann tritt eine Ausnahme- 
situation ein, die einen impliziten Betriebssystemaufruf bewirkt. Im Rahmen 
dieses Betriebssystemaufrufes wird das ausgelagerte Memory von der 

20 Festplatte gelesen und in das physikalische Memory (Arbeitsspeicher) 
geschrieben. Anschliefiend greift die Task erfolgreich auf das gewunschte 
Memory zu, ohne den automatischen Betriebssystemaufruf bemerkt zu 
haben. Ein derartiger implizierter Betriebssystemaufruf wahrend der Lauf- 
zeit der direkt aufgerufenen Zielfunktion wurde einen kritischen Zustand 

25 provozieren, da der Scheduler des Betriebssystems davon ausgeht, daB der 
Kontext des Servers und nicht der Kontext des Clients aktiviert ist. 

Damit solche Ausnahmesituationen ausgeschlossen werden konnen, muB die 
Auslagerung des Memorys, auf das die Zielfunktion zugreift, verhindert 
30 werden. Die Betriebssysteme bieten Mechanismen an, um die Auslagerung 
von Memory zu verhindern. Dieser Vorgang wird als Locking (deutsche 
Bedeutung „Sperren") bezeichnet. Zum Einhalten der Ersten Clientbedin- 
gung muB daher das gesamte Memory, das im Zugriff der Zielfunktion liegt, 
gelockt sein. 

35 

Der Client erfullt die Zweite Clientbedingung durch Unterlassung des 
Zielfunktionsaufrufes in den Zeitpunkten, in denen die Moglichkeit besteht, 
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daB der Server die Zielfunktion aufruft. Da der Server zum Aufrufen der 
Zielfunktion vom Client aktiviert werden mufi, kann der Client wahrend 
einer derartigen Aktivierung den Aufruf der eigenen Zielfunktion blockie- 
ren. 

5 

Der Client erfullt die Dritte Clientbedingung durch Beschrankung auf 
atomare Datenzugriffe oder iiber eine Verriegelung durch Flaggen beim 
Zugriff auf Daten, die durch den Aufruf der Zielfunktion verwendet oder 
verandert werden konnten, wenn die Moglichkeit besteht, daB der Server die 
10 Zielfunktion aufruft. 

Soweit waren die Bedingungen fur den Aufruf der Zielfunktion durch einen 
Kontextwechsel in der Startfunktion geklart. 

15 Allerdings gehort das Locken (Sperren) von Programmcode und Daten in 
seiner notwendigen Gesamtheit nicht zu den Standardaufgaben der Software- 
entvvicklung. Es ist daher wahrscheinlich, daB dabei Fehler gemacht werden. 
Es besteht ferner die Schwierigkeit, daB die Betriebssysteme in Abhangigkeit 
vom Bedarf anderer Tasks das Memory einer bestimmten Task auslagern. 

20 Das Auslagern geschieht also zu unvorhersehbaren Zeitpunkten. Da die 
Betriebssysteme zu nicht vorhersehbaren Zeitpunkten auslagern. ist es nicht 
testbar, ob alle notwendigen Speicherbereiche gelockt (gesperrt) sind. 
Dieses Testbarkeitsproblem verlangt nach einer Losung, die von der Verfah- 
rensvariante 2 nicht geboten werden kann. 

25 

Ziel der nun beschriebenen Verfahrensvariante 3 ist, daB nicht gelocktes 
Memory der Zielfunktion nicht zu unvorhersehbaren Zeitpunkten, sondern 
unmittelbar beim ersten Aufruf der Zielfunktion erkennbar ist. Dazu wird in 
der Startfunktion kein Kontextwechsel in den Client-Kontext, sondern in 

30 einen neu angelegten Kontext durchgefiihrt. Das Anlegen eines neuen 
Kontextes bedeutet eine Konfiguration der MMU des Prozessors. Der neue 
Kontext wird zusammengesetzt aus Teilkopien des Client-Kontextes und des 
Server-Kontextes. Der neue Kontext wird daher als kopierter Kontext 
bezeichnei und bildet den zweiten Kontext, in den aus dem Server-Kontext 

35 heraus gewechselt wird. Der Clieni-Anteil des kopierten Kontextes umfaBt 
genau diejenigen Teile des Clieni-Kontextes, die gelockiem Memory ent- 
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sprechen. Der Server-Anteil des kopierten Kontextes umfalit die Startfunkti- 
on und alle Daten, die sic verwendet. 

Die Verfahrensvariante 3 lost das Testbarkeitsproblem der Verfahrensvari- 
5 ante 2 dadurch, dafi nicht gelocktes (gesperrtes) Memory auch nicht im 
kopierten Kontext vorhanden ist. Ein Zugriff der Zielfunktion auf solches 
Memory macht sich unmittelbar bemerkbar, da er unzulassig ist, wenn die 
MMU des Prozessors in den kopierten Kontext gewechselt hat. 

10 Im Rahmen der Beschreibung des Verfahrens zum direkten Aufruf einer 
Funktion in einem anderen Memory-Kontext durch Konfiguration der MMU 
des Prozessors wurde anhand der Verfahrensvarianten 1 und 2 die grund- 
satzliche Problematik erlautert. Die Verfahrensvariante 1 ermoglicht nicht 
den direkten Aufruf einer fiir die Ausfiihrung sinnvoller Aufgaben ausrei- 

15 chend komplexen Funktion. Die Verfahrensvariante 2 ist fiir einen derarti- 
gen Aufruf geeignet, weist aber insbesondere Probleme bei der Testbarkeit 
auf. 

Die Verfahrensvariante 3, welche einen Kontextwechsel nicht in den Client- 
20 Kontext, sondern in einen kopierten Speicherkohtext durchfiihrt, wobei das 
• Memory dieses kopierten Speicherkontextes vollstandig gesperrt (gelockt) 
ist, stellt die optimale Ausfiihrungsform der Erfindung dar. 

In Analogic zu Shared-Memory als Mittel zum Erreichen des hochst mogli- 
25 Chen Datendurchsatzes zwischen Tasks liefert das dargestellte erfindungsge- 
maBe Verfahren ein Mittel zum Erreichen der hochst moglichen Determi- 
niertheit fiir einen Ereignisaustausch zwischen Tasks. So wie Shared- 
Memory eine direkte Datenkopplung ermoglicht, so ermoglicht das darge- 
stellte Verfahren eine direkte Ereigniskopplung. 

30 



^ jlc 3}! ^ :)C :)( 



G26P986 



- 12- 

Anspriiche: 

1. Verfahren zum direkten Aufrufen einer Zielfunktion mittels einer 
Startfunktion durch einen Prozessor mil einer Memory-Management-Unit 

5 (MMU) in einem durch ein Betriebssystem betriebenen Computer, dadurch 
gekennzeichnet, daB die Startfunktion Bestandteil einer ersten Task mit 
einem ersten Speicherkontext ist und die Zielfunktion in einem andereri 
Speicherkontext liegt und daB die erste Task einen Kontextwechsel von dem 
ersten in den anderen Speicherkontext durchfuhrt, der nach der Ausfiihrung 

10 der Zielfunktion ruckgangig gemacht wird. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daC zur 
Durchfuhrung des Kontextwechsels das MMU-Steuerregister durch die erste 
Task mit der physikalischen Adresse des Speicherkontextes der Task 

15 beschrieben wird, in dem die Zielfunktion enthalten ist. 

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daB Teile der 
ersten Task sowie der die Zielfunktion enthaltenden zweiten Task in einen 
neuen Speicherkontext kopiert werden und der Kontextwechsel in diesen 

20 neuen Speicherkontext erfolgt. 

4. Verfahren nach Anspruch 3, wobei der Computer einen Arbeitsspei- 
cher (RAM) und einen Massenspeicher, z.B. einer Festplatte, aufweist und 
wobei das Betriebssystem bei Bedarf Teile des Arbeiisspeichers in den 

25 Massenspeicher auslagert, dadurch gekennzeichnet, daB der Speicherbe- 
reich des kopierten Speicherkontextes zumindest wahrend der Laufzeit der 
durch die Startfunktion aufgerufenen Zielfunktion gegen Auslagerung aus 
dem Arbeitsspeicher gesperrt ist. 

5. Verfahren nach einem der vorangehenden Anspriiche, dadurch 
gekennzeichnet, daB die Startfunktion wahrend der Laufzeit der Zielfunkti- 
on einen Taskwechsel durch das Betriebssystem vermeidet, indem sie iiber 
ein Prozessorsteuerregister die Interrupt-Verarbeitung deaktiviert. 
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6. Verfahren nach einem der vorangehenden Anspriiche, dadurch 
gekennzeichnet, daB die Zielfunktion keine Programmschritte umfaBt, die 
einen Aufruf des Betriebssystems beinhalten. 
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7. Verfahren nach einem der vorangehenden Anspriiche, dadurch 
gekennzeichnet, dafi wahrend des Aufrufes der Zielfunktion durch die 
Startfunktion ein erneuter Aufruf der Zielfunktion durch eine Funktion 

5 auBerhalb der Zielfunktion blockiert ist. 

8. Verfahren nach einem der vorangehenden Aiispruche, dadurch 
gekennzeichnet, dafi die die Zielfunktion enthaltende Task nur derart 
Zugriffe auf Daten ausfiihrt, die von der Zielfunktion verwendet oder 

10 verandert werden konnen, dafi die Zugriffe innerhalb eines Prozessortaktes 
abgeschlossen oder iiber Flaggen verriegelt sind. 

9. Softwareprogramm zum Laden in den Arbeitsspeicher eines durch ein 
Betriebssystem betriebenen Computers mit eineni Prozessor mit einer 

15 Memory-Management-Unit (MMU), dadurch gekennzeichnet, dafi es eine 
Task mit einer Startfunktion zur Durchfiihrung eines Verfahrens gemafi 
einem der vorangehenden Anspriiche umfafit. 

10. Softwareprogramm nach Anspruch 9, dadurch gekennzeichnet, dafi 
20 es eine zweite Task mit einer Zielfunktion zur Durchfiihrung eines Verfah- 
rens gemafi einem der vorangehenden Anspriiche umfafit. 



11. Maschinenlesbarer Datentrager mit einem auf dem Datentrager 
abgespeicherten Softwareprogramm nach Anspruch 9 oder 10. 
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Zusammenfassung: 

Die Erfindung betriffi ein Verfahren zum direkten Aufrufen einer Zielfunk- 
tion mittels einer Startfunktion durch einen Prozessor mit einer Memory- 
5 Management-Unit (MMU) in einem durch ein Betriebssystem betriebenen 
Computer. 

Bei heutigen Multitasking-Betriebssystemen wird der Aufruf einer Funktion 
einer ersten Task durch eine zweite Task durch den Task-Scheduler des 
Betriebssystems ausgefuhrt und verwaltet. Der Zeitpunkt der Durchfuhrung 
10 der aufgerufenen Funktion ist unbestimmt und von. dem Betriebssystem 
sowie den im jeweiligen Zeitpunkt durch das Betriebssystem verwalteten 
Tasks abhangig. 

Aufgabe der Erfindung ist es, ein Verfahren zu schaffen, welches einen 
zeitlich bestimmten Aufruf einer Funktion ermoglicht, der unmittelbar im 

15 AnschluB an den Aufruf ausgefuhrt wird. 

Diese Aufgabe wird dadurch gelost, dafi die Startfunktion Bestandteil einer 
ersten Task mit einem ersten Speicherkontext ist und die Zielfunktion in 
einem anderen Speicherkontext liegt und dali die erste Task einen Kon- 
textwechsel von dem ersten in den anderen Speicherkontext durchfuhrt, der 

20 nach der Ausfuhrung der Zielfunktion ruckgangig gemacht wird. 
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